Capitolul 2 Proiectarea logica a bazei de date 


Dupa definirea strategiei de proiectare se trece la proiectarea propriu- 
zisă (numită si proiectarea detaliată) a sistemului. Activităţile fazei de 
proiectare detaliată privesc componentele principale ale oricărui sistem 
informatic, respectiv baza de date, interfețele (formulare, rapoarte, meniu) şi 
programele. Desfăşurarea acestor activităţi nu este secventiala ci, mai curând, 
paralelă şi iterativă. Baza de date trebuie sa reflecte specificaţiile de proiectare 
privind formularele şi rapoartele din sistem, iar proiectarea formularelor şi 
rapoartelor nu poate fi finalizată fără ca schema bazei de date să fie clar 
definită. Totuşi, baza de date reprezintă „nucleul” oricărui sistem informatic, în 
jurul său „gravitând” celelalte componente, motiv pentru care ne vom opri mai 
întâi asupra problematicii proiectării bazelor de date. 

Principalele activităţi care formează ciclul de viaţă al bazei de date sunt: 
proiectarea schemei logice, proiectarea fizică a bazei de date şi alocarea 
datelor în reţea, implementarea şi întreţinerea bazei de date. In acest capitol 
ne vom opri doar asupra proiectării schemei logice a bazei de date, respectiv a 
schemei relationale dat fiind că modelul relational reprezintă astăzi de departe 
modul de organizare al datelor cel mai utilizat. Mai întâi însă, vom prezenta 
câteva consideraţii generale privind activităţile de modelare a datelor parcurse 
de-a lungul ciclului de viaţă a sistemelor care, sperăm, vor avea darul de a 
oferi o mai buna intelegere a principiilor, conceptelor şi activităţilor de 
proiectare a bazelor de date. În finalul capitolului vom prezenta câteva 
consideraţii privind gestiunea tranzacţiilor într-o bază de date. 


2.1 Aplicarea principiului abstractizării în modelarea datelor 


Principiul abstractizării reprezintă unul din principiile fundamentale 
aplicate în proiectarea sistemelor informatice. După cum vom vedea ulterior, el 
este utilizat şi la proiectarea arhitecturii programelor. Aplicarea sa permite 
stăpânirea complexităţii sistemului prin luarea în considerare în mod eşalonat a 
diferitelor aspecte ale proiectării sistemului. La un moment dat, analiştii se vor 
concentra doar asupra anumitor aspecte, ignorându-le pe celelalte, dar care 
vor fi luate în considerare ulterior. 

Concret, aplicarea principiului abstractizarii în modelarea datelor 
presupune considerarea a trei niveluri de abstractizare, prezentate în figura 
2.1: conceptual, logic şi fizic. Corespunzător celor trei niveluri pot fi identificate 
trei activităţi de bază în proiectarea bazelor de date: 

e analiza cerinţelor sistemului şi modelarea conceptuală a datelor, 
e proiectarea logică a bazei de date şi 
e proiectarea fizică a bazei de date. 

Prin modelarea conceptuală a datelor se urmăreşte construirea unui 
model al datelor care să asigure transpunerea exactă a realităţii din domeniul 
analizat, fără a lua în considerare cerinţele specifice unui model de organizare 
a datelor (cum este modelul relational), criteriile de calitate privind organizarea 
datelor, cerinţele nefunctionale ale sistemului şi criteriile de performanţă 
privind stocarea şi accesarea datelor. În acest sens, se construieşte diagrama 
entitate-relatie, care evidenţiază entităţile de date din sistem, atributele 
acestora, precum şi legăturile dintre entităţi. Modul în care vor fi implementate 
legăturile dintre entităţi, de exemplu, nu interesează în acest moment, atenţia 
fiind îndreptată doar spre identificarea şi descrierea lor. 


Proiectarea logica presupune organizarea datelor in tabele si coloane, 
conform regulilor modelului relational (acesta fiind modelul cel mai popular de 
organizare a datelor). După cum se poate observa din figura 2.1, proiectarea 
logică a bazei de date presupune transformarea modelului conceptual al 
datelor prin aplicarea regulilor şi conceptelor specifice modelului relational şi a 
criteriilor de calitate aplicabile modelului logic al datelor, aspecte ignorate în 
etapa modelării conceptuale. Scopul urmărit constă în obţinerea unui model 
relational pur, adică neafectat de cerinţele nefunctionale si cele de 
performanta in accesarea datelor, nici de facilitatile oferite de diferite SGBD-uri 
existente pe piaţă. Toate aceste aspecte sunt înglobate în etapa proiectării 
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Figura 2.1 Nivelurile de abstractizare a datelor 


Principalele criterii de calitate utilizate in evaluarea modelului logic al 
datelor sunt: 

e Completitudine. Modelul logic trebuie sa conţină toate datele 
necesare prelucrărilor şi obţinerii ieşirilor din sistem. 

e Neredundanta. Redundanta datelor generează probleme privind 
integritatea datelor (vezi anomaliile la actualizare) şi solicită 
procese suplimentare pentru întreţinerea datelor (vor trebui 
actualizate toate copiile existente pentru o dată). De aceea, 
modelul logic trebuie să fie format dintr-un set de tabele 
normalizate. 

e Reutilizabilitate. Schema logică a bazei de date trebuie concepută 
astfel încât ea să satisfacă nu doar cerinţele anticipate ale 
sistemului ci şi cele ale altor potenţiali utilizatori sau eventualele 
cerinţe viitoare care apar inevitabil. Dacă datele sunt organizate 
având în minte doar cerinţele actuale, atunci reorganizarea datelor 
determinată de apariţia unor noi cerinţe funcţionale va fi foarte 
costisitoare. 

e Stabilitate şi flexibilitate. Aceste criterii vizează uşurinţa adaptării 
bazei de date la modificările ulterioare ale cerinţelor sistemului. Un 
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model al datelor este considerat stabil daca eventualele modificari 
ale cerintelor functionale nu determina modificarea sa. Schema 
bazei de date va fi considerată mai stabilă sau mai putin stabilă în 
funcţie de amploarea modificărilor generate de schimbarea 
cerinţelor. Flexibilitatea unui model al datelor este dată de uşurinţa 
extinderii sale pentru înglobarea noilor cerinţe cu impact minim 
asupra structurii existente. 

e Simplitate şi eleganță. Modelul logic al datelor trebuie să ofere o 
clasificare naturală şi elegantă a datelor. De exemplu, este 
inadecvată existenţa tabelelor Furnizor şi Client atât timp cât unii 
parteneri de afaceri pot fi atât furnizori, cât şi clienţi. Aceeaşi 
situaţie poate apare în cazul facturilor, fiind neelegantă conceperea 
a două tabele, una pentru facturi emise şi alta pentru facturi 
primite. 

Modelul fizic al datelor, rezultat în urma proiectării fizice, este invizibil 
utilizatorilor şi programatorilor. El specifică modul de stocare fizică şi accesare 
a datelor, utilizând facilităţile oferite de un anumit SGBD. De exemplu, date din 
tabele diferite pot fi stocate fizic împreună pentru a putea fi transferate în 
memoria calculatorului printr-o singură operaţiune. Luarea în considerare a 
acestor aspecte implică „alterarea” modelului logic (adică a modelului 
relational pur), presupunând uneori prejudicierea aspectelor calitative amintite 
anterior. Soluţia ideală ar presupune obţinerea performanţelor cerute în 
condiţiile păstrării aspectelor calitative ale modelului logic. 

Obiectivul principal al proiectări fizice constă în optimizarea 
performanţelor bazei de date în ce priveşte stocarea fizică şi accesul la date. În 
unele situaţii timpii de acces ceruti pot fi obţinuţi prin intermediul indecsilor 
însă, de multe ori este necesară modificarea structurii logice a datelor prin 
procesul denormalizării. Dacă la proiectarea schemei logice s-a urmărit 
prezervarea integrităţii datelor prin procesul de normalizare, acum poate 
deveni necesară introducerea unui anumit nivel de redundanta a datelor sau 
introducerii în schema bazei de date a câmpurilor calculate. Principala 
provocare constă în găsirea compromisului optim între uşurinţa păstrării 
integrităţii datelor şi performanţele bazei de date. Denormalizarea implică 
selectarea proceselor dominante (interogare şi actualizare a datelor) pe baza 
frecvenţei, volumului de date şi priorităţii acestora, evaluarea costurilor totale 
ale operaţiunilor de actualizare, interogare şi stocare a datelor, precum şi 
evaluarea efectelor determinate de pierderea integrităţii datelor. 

De asemenea, la proiectarea fizică vor fi luate în considerare şi facilităţile 
oferite de SGBD-ul ales. Diferenţele dintre diferite SGBD-uri se referă adesea la 
tipurile de date suportate, reprezentarea sau nu a relaţiilor dintre clase şi 
subclase, implementarea relaţiilor recursive. 

Prin urmare, schema logică a bazei de date poate diferi, mai mult sau 
mai puţin, de schema fizică a bazei de date. 


2.2 Demersul proiectării bazelor de date 


Proiectarea schemei logice a bazei de date poate fi realizată în mai multe 
moduri. Abordarea tradiţională, aplicată în special bazelor de date relationale, 
presupune constituirea relaţiei universale prin reunirea tuturor datelor 
elementare (atribute) identificate în faza de analiză şi repartizarea lor în tabele 
pe baza analizei dependentelor dintre atribute (dependențe funcţionale, 


dependente multivaloare si de jonctiune) şi aplicarea procesului de 
normalizare. Această abordare a înregistrat unele succese în cazul bazelor de 
date de dimensiuni mici şi medii, însă ea devine foarte greoaie în cazul bazelor 
de date de dimensiuni mari şi foarte mari. 

Introducerea modelului entitate-relatie (ER) a determinat reorientarea 
specialiştilor către o nouă abordare în proiectarea bazelor de date. Modelarea 
conceptuală a datelor cu ajutorul diagramelor entitate-relatie (DER) a fost 
descrisă prima dată în lucrările lui P.P. Chen, publicate în 1976, deşi primele 
încercări de formalizare sunt înregistrate în anii '60 şi aparţin lui Charles 
Bachman. Ulterior, modelul lui Chen a înregistrat numeroase modificări şi 
extensii. Simplitatea, uşurinţa învăţării şi posibilitatea formalizării cerinţelor 
sistemului aşa cum sunt ele în realitate, independent de opţiunile de 
organizare şi tehnologice au sporit vertiginos popularitatea modelului ER încă 
din anii '80. 

Noua abordare presupune, mai întâi, modelarea conceptuală a datelor 
prin construirea diagramei entitate-relatie (DER), care evidenţiază entitatile de 
date ale sistemului, proprietăţile acestora şi legăturile dintre entităţi. Ulterior, 
prin aplicarea unor reguli simple, are loc transformarea modelului entitate- 
relaţie în schema logică a bazei de date. Tabelele astfel obţinute sunt în final 
analizate din perspectiva normalizării putând rezulta noi tabele. 

Utilizarea modelului ER oferă o serie de avantaje faţa de abordarea 
tradiţională”: 

e reprezintă un util instrument de comunicare între proiectanți 
şi utilizatorii finali pe parcursul fazelor de analiză şi proiectare 
logică; 

e este foarte uşor de înţeles şi conceput. În general, 
prezentarea grafică permite exprimarea unui volum mare de 
informaţii sub o formă compactă, uşor de urmărit şi înţeles; 

e utilizează conceptul de abstractizare, ceea ce reduce 
considerabil numărul obiectelor luate în considerare la analiza şi 
proiectarea bazei de date. Prin utilizarea noţiunii de entitate ca 
abstractizare pentru datele elementare (atribute) se vor analiza 
mai puţine obiecte (numărul entitatilor de date este mult mai mic 
decât numărul datelor elementare din sistem) şi mai puţine relaţii 
între obiecte (numărul relaţiilor dintre entităţi este mult mai mic 
decât numărul relaţiilor de dependenţă existente între atribute). 
Deşi datele elementare sunt reprezentate şi în această abordare, 
ca proprietăţi ale entităţilor, totuşi numărul dependentelor ce 
trebuie analizate este mult redus, fiind luate în considerare doar 
dependentele la nivelul entităţilor (adică dependentele dintre 
atributele unei entităţi) şi nu la nivelul întregii baze de date (adică 
dependentele dintre atributele relaţiei universale). 

e Existenţa unui set complet de reguli de transformare a DER 
în tabele ale bazei de date. Aceste reguli permit transformarea 
simplă şi rapidă a cerinţelor informaţionale ale sistemului, 
structurate în DER, în baza de date. Majoritatea instrumentelor 
CASE oferă suport pentru generarea automată a bazei de date în 
funcţie de SGBD-ul dorit. 

Din cele prezentate rezultă că există două strategii de proiectare a bazei 
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de date: 

e strategia bottom-up, reprezintă abordarea tradiţională si 
presupune constituirea relaţiei universale care urmează a fi supusă 
normalizării pentru a se obţine tabelele bazei de date; 

e strategia top-down, presupune construirea DER care va fi apoi 
transformată într-un set de tabele prin aplicarea unor reguli. 
Tabelele astfel obţinute vor fi analizate din perspectiva normalizării. 

Pornind de la aceste două strategii, pot fi identificate mai multe 
demersuri de proiectare a bazei de date, mai mult sau mai puţin riguroase. 
Două dintre ele corespund celor două strategii, ele fiind descrise pe scurt 
anterior. Un demers mai riguros presupune combinarea celor două strategii; se 
aplică ambele strategii obținându-se două modele logice ale datelor, iar din 
compararea lor va rezulta schema logică finală a bazei de date. Acest demers 
presupune parcurgerea următorilor patru paşi: 

1. Construirea câte unui model logic al datelor pentru fiecare 
categorie de utilizatori identificată. Acest pas presupune 
normalizarea imaginilor asupra bazei de date (formulare şi 
rapoarte) specifice fiecărei categorii de utilizatori. 

2. Integrarea perspectivelor, care presupune combinarea tuturor 
perspectivelor normalizate ale utilizatorilor şi obţinerea schemei 
globale a bazei de date. 

3. Intocmirea modelului conceptual al datelor pentru întregul sistem 
şi transformarea acestuia într-un set de tabele normalizate. 

4. Compararea modelului logic consolidat al datelor rezultat prin 
integrarea  perspectivelor utilizatorilor cu cel obţinut prin 
transformarea DER, în vederea definirii modelului logic final. 

În practică, poate fi angajat un alt demers mai simplu (sau simplist!) de 
proiectare a bazei de date, constând în transpunerea directă a cerinţelor 
sistemului în modelul logic al datelor, fără parcurgerea unor paşi intermediari. 
Un asemenea demers poate fi aplicat în cazul bazelor de date de dimensiuni 
foarte mici sau dacă proiectantul are o mare experienţă în domeniul problemei. 
Oricum, alegerea unui demers sau a altuia depinde de complexitatea bazei de 
date, experienţa echipei de proiectare, timpul şi resursele financiare 
disponibile sau cerinţele de calitate dorite. 

In continuare ne vom opri doar asupra strategiei „top-down”, 
normalizarea fiind discutată la cursul „Baze de date”. Vom prezenta activităţile, 
conceptele şi regulile de lucru utilizate în aplicarea acestei strategii. 


2.3 Analiza cerinţelor sistemului şi modelarea conceptuală a 
datelor 


Analiza cerinţelor informaţionale ale noului sistem reprezintă etapa cea 
mai importantă din ciclul de viaţă al bazei de date, implicând şi volumul cel 
mai mare de muncă. Inglobarea tuturor acestor cerinţe in schema finală a 
bazei de date reprezintă o provocare pentru proiectanți. Culegerea cerinţelor 
se realizează în faza de analiză a sistemului prin intervievarea utilizatorilor sau 
alte metode de determinare a cerinţelor. Obiectivele majore ale analizei 
cerinţelor vizează:: 

e descrierea cerinţelor de date ale sistemului în termenii entităţilor 
de date; 
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e colectarea informaţiilor care descriu entităţile de date şi relaţiile 
dintre acestea care să permită construirea DER; 

e determinarea tranzacţiilor ce vor fi efectuate asupra bazei de date 
şi descrierea interacțiunii dintre tranzacţii şi entităţile de date; 

e definirea cerinţelor nefunctionale ale bazei de date, cum ar fi cele 
legate de performanţe, integritate, securitate, administrarea 
datelor; 

e specificarea platformei hardware si software pe care va fi 
implementata baza de date. 

Dupa formularea clara a cerintelor se trece la formalizarea acestora, 
respectiv intocmirea DER. Modelul ER este construit pe baza a trei clase de 
obiecte: entitati, atribute si relatii. Atributele descriu entitatile si relatiile dintre 
acestea. Prin urmare, aceasta activitate presupune parcurgerea a doi pasi: 

e identificarea si descrierea entităţilor şi 

e definirea relaţiilor dintre entităţi. 


2.3.1 Identificarea şi descrierea entităţilor de date 


Prin entităţi de date se face referire la obiectele despre care este nevoie 
să se memoreze informaţii. De regulă, ele se referă la locuri, persoane, lucruri, 
evenimente în legătură cu care există interes din perspectiva stocării datelor. 
Un caz particular al unei entităţi este numit instanţă sau ocurenta. Astfel, o 
entitate va conţine mai multe instanţe de acelaşi tip, adică instanţe cu 
proprietăţi comune. Unii autori utilizează noţiunile de clasă de entităţi şi 
entitate pentru entitate şi, respectiv, instanţă. 

Exemple de entităţi sunt: angajat, care va avea drept instanţe toţi 
angajaţii dintr-o firmă; furnizor, care va conţine toţi partenerii de afaceri cu 
care firma are relaţii de aprovizionare; consum, care va avea drept instanţe 
toate documentele de consum înregistrate într-o perioadă de timp în firmă. 
Alte exemple pot fi: departament, produs, student, disciplina, profesor, 
localitate etc. 

O entitate este descrisă prin intermediul atributelor. Atributele 
reprezintă proprietăţi ale entității pe care o descriu, toate instanţele unei 
entităţi fiind descrise de aceleaşi atribute. Un atribut al unei instanţe dintr-o 
entitate se numeşte valoarea atributului. De exemplu, atributele care 
caracterizează entitatea angajat pot fi: marca, numele, adresa, numărul de 
telefon, CNP, funcţia, salariul etc. 

Există două tipuri de atribute: identificatori şi descriptori. Un 
identificator (numit şi cheie) are rolul de a identifica în mod unic fiecare 
instanţă care poate popula o entitate de date. În schimb, descriptorii specifică 
caracteristici ne-unice ale instanţelor unei entităţi. 

Depistarea entităţilor unui sistem nu reprezintă o activitate tocmai 
uşoară. In multe situaţii analistul trebuie să decidă dacă un obiect reprezintă o 
entitate, un atribut al unei entităţi sau o relaţie între entităţi. Să luăm drept 
exemplu obiectul Jocalitate; el reprezintă o entitate sau un atribut? În sistemul 
de aprovizionare, el ar putea reprezenta o entitate sau doar atributul entității 
furnizor. Un alt exemplu este comanda; reprezintă comanda o entitate sau o 
relaţie între entităţile Material şi Furnizor? 

La clasificarea entităţilor şi atributelor trebuie respectate următoarele 
două reguli: 

e entităţile trebuie să conţină informaţii descriptive. Conform 


acestei reguli, dacă pentru un obiect există informaţii descriptive 
(adică mai multe atribute care să o caracterizeze) atunci acel 
obiect constituie o entitate. Altfel, dacă pentru obiectul respectiv 
este necesar doar un identificator, nefiind solicitate atribute de tip 
descriptori, atunci acel obiect va reprezenta un atribut. Dacă 
pentru obiectul Localitate sunt necesare mai multe informaţii 
descriptive (cum ar fi judeţul, regiunea, numărul populaţiei etc.) 
atunci el trebuie clasificat ca entitate. Dacă se solicită doar numele 
localităţii, atunci el va fi doar un atribut al unei entităţi (cum ar fi 
furnizor, angajat, departament etc.). 

e un atribut trebuie ataşat acelei entităţi pe care o descrie în 
modul cel mai direct. De regulă, o proprietate se referă la o 
singură entitate, deci un atribut va fi regăsit doar la o singură 
entitate. În sistemul de aprovizionare, de exemplu, entitatea 
Comandă nu va conţine nici numele furnizorului (sau codul 
acestuia), nici denumirea materialului (sau codul materialului); 
aceste atribute caracterizează mai direct entităţile Furnizor şi, 
respectiv, Material. Nu intra sub incidenţa acestei reguli 
sinonimele. Un exemplu în acest sens poate fi atributul adresa: el 
poate caracteriza atât entitatea angajat, cât şi entitatea furnizor. 

Aşadar, clasificarea unui obiect ca entitate sau atribut presupune analiza 
cu multă atenţie a documentaţiei sistemului în care sunt formulate şi detaliate 
cerinţele informaţionale. 


2.3.2 Definirea relaţiilor dintre entităţile de date 


O relaţie reprezintă legătura care există în lumea reală între una, două 
sau mai multe entităţi. Relaţiile nu au o existenţă fizică sau conceptuală, ci 
depind de entităţile asociate. Altfel spus, existenţa relaţiilor depinde de 
existenţa entităţilor asociate (în schimb existenţa unei entităţi nu depinde de 
existenţa unei relaţii cu o altă entitate). Un caz particular al unei relaţii se mai 
numeşte instanţa relaţiei sau ocurenta relaţiei. Instanţa relaţiei se referă 
la legătura dintre instanţele entităţilor asociate. Exemple de relaţii sunt: emite, 
între entităţile Factura şi Furnizor; conţine, între entităţile Factura şi Produs; 
este condus, între entităţile Departament şi Angajat sau orice verb care care 
descrie conexiunea dintre entităţi. 

Descrierea unei relaţii presupune specificarea următoarelor elemente: 
ordinul (gradul), cardinalitatea, rolul şi eventualele atribute care o 
caracterizează. In continuare ne vom opri pe rând asupra fiecărui element 
descriptiv. 

Ordinul relaţiei este dat de numărul entităţilor asociate printr-o relaţie. 
Conform acestui criteriu, relaţiile pot fi clasificate în: 

e relații recursive, numite şi relaţii ale entității cu ea însăşi. Acest tip 
de relaţie leagă două instanţe ale aceleiaşi entităţi. Un exemplu de 
relaţie recursivă se regăseşte în figura 2.10. 

e relații binare, în care sunt implicate două entităţi. Acest tip de 
relaţii sunt de departe cele mai întâlnite în lumea reală. Mai mult, 
unele metode utilizează doar acest tip de relaţii la construirea 
modelului ER. Exemple de relaţii binare se regăsesc în figurile 2.6 - 
2.9 şi 2.10. 

e relații de ordinul n, numite şi relaţii n-are. Acest tip de relaţii se 


stabileşte între trei sau mai multe entităţi. Dacă numărul entităţilor 
implicate într-o relaţie este 3, atunci vom avea o relaţie ternară. 
Astfel de exemple sunt prezentate în figurile 2.12, 2.13 şi 2.14. 
Relaţiile ternare sunt mai rar întâlnite în lumea reală, ele fiind 
utilizate atunci când nu este suficientă utilizarea relaţiilor binare 
pentru descrierea cu acuratețe a semanticii relaţiei respective. 

Următorul element utilizat pentru descrierea relaţiilor îl reprezintă 
cardinalitatea. Cardinalitatea unei relaţii defineşte numărul instanţelor unei 
entităţi care pot fi asociate unei instanţe a celeilalte entităţi prin intermediul 
relaţiei considerate. Pentru o relaţie dată trebuie specificată cardinalitatea 
pentru fiecare entitate asociată. Cardinalitatea relaţiei pentru o entitate este 
sugerată printr-o pereche de valori, în cazul relaţiilor binare trebuind 
specificate două astfel de perechi de valori. Valorile care compun o astfel de 
pereche semnifică: 

e cardinalitatea minima, pentru care sunt posibile valorile „0” sau 
wl”, şi 

e cardinalitatea maxima, pentru care sunt posibile valorile „1” sau 
„M” (adică „multe”). 

Sa luăm drept exemplu relaţia emite/este emis dintre entităţile Furnizor 
şi Factura, prezentată în figura 2.2. Cardinalitatea minimă a relaţiei pentru 
entitatea Factura este ,,1”, iar cea maxima este tot ,,1”; cardinalitatea relaţiei 
pentru entitatea Furnizor este „0”, respectiv „M”. Prin urmare, în relaţia 
emite/este emis, unui furnizor (care este o instanţă a entității Furnizor) îi 
poate corespunde minim 0 şi maxim „multe” facturi (adică instante ale entității 
Factura), în timp ce unei facturi îi corespunde minim un furnizor şi maxim tot 
un furnizor. Dacă luăm în considerare şi numele relaţiei (sau rolurile entităţilor 
în cadrul relaţiei), atunci o relaţie poate fi citită în ambele sensuri astfel: 

„un furnizor emite 0 sau mai multe facturi”, respectiv 

„O factură este emisă de un furnizor şi numai unul”. 


(0,M) (1,1) 


Figura 2.2 Cardinalitatea relatiilor 


Anterior am prezentat clasificarea relatiilor in functie de gradul lor. Un alt 
criteriu de clasificare a relatiilor este legat de cardinalitatea maxima. Astfel, in 
cazul relatiilor recursive si al celor binare vom avea trei tipuri de relatii: 

e relaţii de tipul 1:1 (unu-la-unu), adică o instanţă a entității X 
este asociată unei singure instante a entității Y şi reciproc. Exemple 
se regăsesc în figurile 2.6 şi 2.7. 

e relaţii de tipul 1:N (unu-la-multe), însemnând că o instanţă a 
entității X poate fi asociată la n instante ale entității Y, în timp ce o 
instanţă a entității Y va fi asociată doar unei singure instante a 
entității X. Acest tip de relaţii este cel mai des întâlnit în lumea 
reală, exemple fiind prezentate în figurile 2.8 şi 2.9. 

e Relaţii de tipul M:N (multe-la-multe), care presupun ca orice 
instanţă a entității X poate fi asociată mai multor instante ale 
entității Y, iar o instanţă a entității Y poate de asemenea să aibă 
asociate mai multe instante ale entității X (vezi figura 2.11). 

Generalizând, se poate afirma că o relaţie de ordinul n va înregistra n+1 


tipuri de relatii din punctul de vedere al cardinalitatii maxime. Daca, dupa cum 
deja am vazut, in cazul unei relatii de ordinul 2 avem 3 tipuri de relatii, pentru 
o relaţie de ordinul 3 (relaţie ternara) vom avea 3+1=4 tipuri de relaţii: 1:1:1, 
1:1:P, 1:N:P şi M:N:P(multe-la-multe-la-multe). Exemple pentru aceste 
tipuri de relaţii sunt prezentate în figurile 2.12, 2.13 şi 2.14. 

Am discutat până acum importanţa cardinalităţii maxime, însă si 
cardinalitatea minimă are o semnificaţie importantă în proiectarea bazelor 
de date, ea fiind legată de conceptul de restricţie de dependenţă”. Dacă 
existenţa instanţei x din entitatea X depinde de existenţa instanţei y din 
entitatea Y, se spune că x este dependentă de y; de aici rezultă că ştergerea 
entității y atrage automat ştergerea entității x din baza de date. Se spune că 
existenţa instanţei x depinde de existenţa instanţei y. Entitatea Y este 
denumită entitate dominantă, iar entitatea X este denumită entitate 
dependentă. 

Revenind la exemplul anterior cu relaţia emite/este emisa, entitatea 
Factura este dependentă de entitatea Furnizor, deci Furnizor este o entitate 
dominantă. Ştergerea unei facturi nu atrage automat şi ştergerea furnizorului 
care a emis-o, deoarece este posibil ca în baza de date să mai rămână facturi 
primite de la furnizorul respectiv. În schimb, ştergerea unui furnizor atrage 
după sine ştergerea tuturor facturilor aferente acestuia. 

Relaţiile dintre entităţi pot fi clasificate după cardinalitatea minimă în 
două tipuri: relaţii facultative şi relaţii obligatorii. Altfel spus, participarea 
unei entităţi într-o relaţie poate fi facultativă sau obligatorie; participarea 
opţională este pusă în evidenţă prin cardinalitatea minima „0” pentru o 
entitate, iar cardinalitatea minimă „1” semnifică faptul că acea entitate este 
obligatoriu să participe într-o relaţie. Se observă că în relaţia emite/este emisă 
entitatea Factura are cardinalitatea minima ,1”, deci este obligatorie 
participarea oricărei instanţe (facturi) într-o relaţie, în timp ce cardinalitatea 
minimă pentru entitatea Furnizor este „0”, ceea ce înseamnă că nu este 
obligatorie participarea fiecărui furnizor în relaţia emite/este emisă (va putea 
exista un furnizor care să nu participe în nici o relaţie). 

Rolul defineşte funcţia care atrage entitatea într-o relaţie. Pentru o 
relaţie trebuie specificat rolul fiecărei entităţi asociate. De exemplu, în relaţia 
dintre Factura şi Furnizor exemplificată în figura 2.2, rolul entității Furnizor 
este Emite, iar cel al entității Factura este este emisă. Specificarea rolurilor 
jucate de entităţi în DER ajută la clarificarea aspectelor semantice ale 
modelării datelor, precum şi la citirea relaţiilor, după cum s-a văzut anterior. 
Prin combinarea rolurilor jucate de entităţile asociate se obţine numele relaţiei 
(emite/este emisă). Totuşi, unele metode de recomandă utilizarea unui singur 
nume pentru o relaţie, stabilit prin alegerea unui substantiv care să reflecte 
logica legăturii dintre entităţile respective. De exemplu, pentru relaţia din 
figura 2.2 se poate utiliza numele Cumpărare sau Emitere. În această variantă, 
rolul fiecărei entităţi nu mai este specificat în mod explicit, însă el rezultă 
implicit din numele atribuit relaţiei. În lipsa unui substantiv semnificativ pentru 
logica relaţiei se poate alege un nume format din inițialele entităţilor asociate. 

In sfârşit, descrierea relaţiilor impune şi specificarea atributelor 
asociate, dacă ele există. De exemplu, relaţia Examen dintre entităţile Student 
şi Disciplină are ca atribute proprii Data exam şi Nota. Întradevăr, atributul 


t Korth, H.F., Silberschatz, A., Sistemes de gestion de bases de donees, McGraw-Hill, Paris, 
1988, citat in Fotache, M., Baze de date relationale. Organizare si interogare, Ed. Junimea, lasi, 
1996, p. 69 


Nota reprezinta o proprietate relatiei dintre un student si o disciplina la care 
susţine examen, adică o proprietate a relaţiei stabilite între două instante ale 
celor două entităţi. Dacă Nota ar fi atribuită uneia din cele două entităţi, atunci 
am avea un atribut multivaloare, deoarece un student poate avea mai multe 
note (pentru fiecare disciplină la care a susţinut examen), iar la o disciplină ar 
putea exista mai multe note (pentru fiecare student care a susţinut examen la 
disciplina respectivă). Modul de repezentare grafică a atributelor asociate 
relaţiilor este prezentat în figura 2.3. Dacă unele notații nu utilizează un simbol 
special pentru relaţii (aşa cum este rombul în figura 2.3) atunci se va introduce 
în diagramă o entitate asociativă care, pentru moment, nu va avea cheie 
primară. 

Relaţii purtătoare de atribute sunt întâlnite doar în cazul relaţiilor binare 
de tipul „multe-la-multe” sau a relaţiilor ternare. Relaţiile binare de tipul „unu- 
la-unu” sau „unu-la-multe” nu pot avea atribute, deoarece cel puţin una dintre 
entităţile asociate prezintă cardinalitatea maximă „unu”, ceea ce înseamnă că 
eventualele atribute ale relaţiei vor putea fi ataşate unei entităţi fără 
ambiguitate. 


Figura 2.3 Exemplu de relaţie purtătoare de atribute 


Aplicarea tuturor conceptelor prezentate anterior permit descrierea 
suficient de clară a tuturor relaţiilor între entităţi identificate în domeniul 
problemei analizate. O atenţie deosebită trebuie acordată relaţiilor 
redundante. Două sau mai multe relaţii sunt considerate redundante atunci 
când ele sunt utilizate pentru a reprezenta acelaşi concept. Un exemplu de 
relaţie redundantă este cea dintre Furnizor şi Plata din figura 2.4. Relaţia 
dintre Furnizor şi Plata este mai curând una indirectă, deoarece se urmăreşte 
plata facturilor primite. Dacă s-ar ţine o evidenţă globală a datoriilor către 
furnizori, atunci ar trebui eliminată relaţia dintre Factura şi Plata. Indiferent de 
tipul de evidenţă, una din Saheb aia relaţii trebuie eliminata. 


a 


(1,1) (0,m) 


(0,m) (1,m) 


Figura 2.4 Exemplu de relatie redundanta 
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În schimb, în figura 2.5 nici una dintre cele trei relaţii nu este redundanta 
atât timp cât membrii unei asociaţii pot locui în altă localitate decât cea în care 
îşi are sediul asociaţia. Dacă ar exista restrictia ca toţi membrii unei asociaţii sa 
locuiască în localitatea de reşedinţă a asodiaţiei, atunci relaţia dintre Membru 
şi Localitate ar fi redundantă. 


0,M 
ue 
(1,M) (1,1) 
Apartine 
(0,M) —= (0,M) 
Este localizată 


Figura 2.5 Exemplu de relaţii neredundante 
2.4 Reguli de transformare a DER|în schema relationala 


Transformarea DER în schema relatjonala a bazei de date presupune 
analiza atentă a DER, luându-se în comsiderare ordinul şi cardinalitatea 
legăturilor, precum şi atributele multivaloare. În urma acestor transformări pot 
rezulta patru tipuri de tabele: 

1 Tabele care vor avea acelaşi conţinut ca entităţile originale. 
Acest tip de tabele rezultă din transformarea entităţilor implicate în relaţii 
binare de tipul „multe-la-multe”, a celor situate în partea „unu” a unei relaţii 
binare „unu-la-multe”, sau a uneia din cele două entităţi aflate într-o relaţie 
„unu-la-unu”; acelaşi tip de tabele pot rezulta şi din transformarea entităţilor 
cu relaţii recursive de tipul „multe-la-multe” sau a entităţilor implicate în relaţii 
ternare sau cu ordinul mai mare de trei. Cheia acestor tabele va fi reprezentată 
de cheia principală a entității originale, iar celelalte proprietăţi ale entității vor 
deveni atribute non-cheie în tabela rezultată. Aceste tabele vor juca rolul de 
părinte. 

2 Tabele care vor îngloba cheia straină a entității părinte. 
Acest tip de transformări apar în cazul entităţilor aflate de partea „multe” a 
unei relaţii binare de tipul „unu-la multe”, a uneia dintre entităţile legate printr- 
o relaţie „unu-la unu”, precum şi a entităţilor cu legături recursive de tipul 
„unu-la-unu” sau  „unu-la-multe”. Tabelele rezultate în urma acestor 
transformări vor juca rolul de tabelă copil. Ele vor avea ca atribute proprietăţile 
entității originale, la care se adaugă cheia principală a entității cu care este 
legată şi care va juca rolul de cheie straină. 

3 Tabele care vor conţine cheile tuturor entităţilor implicate 
într-o relaţie. Aceste tabele mai sunt numite şi entități asociative. Ele derivă 
din descompunerea legăturilor binare sau recursive de tipul „multe-la-multe”, 
sau a legăturilor ternare sau de un ordin mai mare de trei. O astfel de tabelă va 
conţine cheile primare ale entităţilor asociate ca chei străine, precum şi 
eventualele proprietăţi ale relaţiei. Cheia principală a tabelei este formată, de 
regulă, prin combinarea cheilor străine. 

4 _ Tabele care vor conţine atributele multivaloare ale unei 
entităţi. In cazul în care o entitate conţine unul sau mai multe atribute 
multivaloare, atunci se va constitui o nouă tabelă care va conţine atributele 
multivaloare, preluând şi cheia entității originale. De regulă, cheia principală a 
tabelei va fi formată din cheia entității originale la care se adaugă unul sau mai 
multe din celelalte atribute. 


11 


Regulile anterioare de transformare iau in considerare numai maximul 
cardinalitatii relaţiilor dintre entităţi. Minimul cardinalitatii, care descrie 
caracterul obligatoriu/facultativ al unei relaţii, indică dacă pentru cheile străine 
sunt permise valorile nule sau nu. În acest sens, se va lua în considerare 
minimul cardinalitatii unei relaţii din partea entității părinte (adică în partea 
relaţiei în care maximul cardinalitatii este 1); dacă relaţia este opţională, atunci 
se vor permite valorile nule pentru cheia straină în tabela-copil; în cazul 
relaţiilor obligatorii nu se vor permite valori nule pentru cheile străine. 

Transformarea DER într-un set de tabele normalizate presupune 
parcurgerea a doi paşi: 

e Reprezentarea entităților, în care se obţin tabele din prima 
categorie; 

e Reprezentarea relațiilor dintre entități, activitate în urma căreia vor 
rezulta tabele din a doua şi a treia categorie. 

e Reprezentarea atributelor multivaloare, caz în care se vor obţine 
tabele din ultima categorie, numite şi entităţi atributive. 

Reprezentarea entităţilor este o transformare simplă, motiv pentru care 
în continuare vom prezenta exemple de transformare doar pentru ultimii doi 
paşi, respectiv reprezentarea relațiilor şi reprezentarea atributelor 
multivaloare. 


2.4.1 Reprezentarea relațiilor binare 1:1 şi 1:M 


Legăturile binare de tipul 1:1 sunt ilustrate în figurile 2.6 si 2.7. Daca 
ambele entități sunt obligatorii (figura 2.6), atunci fiecare entitate va deveni o 
tabelă iar cheia principală a uneia dintre ele (la alegere) va apare în cealaltă 
tabelă ca cheie străină. O alternativă la această transformare constă în unirea 
celor două entități într-o singură tabelă care va conține ca atribute proprietățile 
ambelor entități şi a cărei cheie principală va aleasă dintre cheile celor două 
entități. Dacă cerințele de acces la date o impun, se poate alege ca ambele 
tabele să conțină cheia străină care să facă referire la cheia principală a 
celeilalte tabele. 

Dacă participarea unei entități în relație este opțională, atunci tabela 
corespunzătoare ei va conţine cheia straina. In figura 2.7, se observă că tabela 
Departament, cea care corespunde entității situate de partea ,,0” a legăturii, 
va fi cea care va conține cheia străină. Situația ar putea fi inversată, în sensul 
ca tabela Angajat să conțină cheia străină, pentru care să fie admise valori 
nule, însă aceasta ar presupune spațiu de stocare suplimentar atât timp cât 
numărul instanțelor entității Angajat este mai mare decât cel al instanțelor 
entității Departament. 


Fiecare factură are în corespondenţă ddReceptie ai una, iar o recepție are la bază exact 
Rec id 


| (1,1) 
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Figura 2.6 Transformarea relatiilor 1:1 in care ambele entitati sunt obligatorii 
In cazul in care participarea ambelor entitati este facultativa, atunci 
oricare din tabelele corespondente poate contine cheia straina, numai ca se 
vor admite valori nule pentru cheia straina. 


| (1,1) 


Figura 2.7 Transformarea relatiilor 1:1 in care participarea uneia dintre entitati 
este facultativa 


În toate cazurile de relaţii 1:N, cheia străină va apare în tabela 
corespunzătoare entității aflate de partea multe a legăturii, fiind tabela copil, 
iar pentru cheia străină sunt acceptate valori nule dacă entitatea din partea 
„unu” a relaţiei este facultativă. Se observă că în relaţia dintre Departament şi 
Raport din figura 2.8 participarea entității Departament are caracater 
facultativ, ceea ce înseamnă că în tabela Raport sunt permise valori nule 
pentru cheia străină. În schimb, la transformarea relaţiei dintre entităţile 
Furnizor si Factura (figura 2.9), în tabela Factura nu sunt permise valori nule 
pentru cheia străină deoarece participarea entității Furnizor este obligatorie în 
relaţia cu entitatea Factura. Participarea facultativă a entității din partea multe 
nu afectează operaţiunea de transformare, ea fiind interpretată prin faptul că 
pot exista înregistrări în tabela părinte fără a avea asociate nici o înregistrare 
în tabela copil. 


(1,M) 


Figura 2.8 Transformarea relaţiilor 1:N în care participarea entității din partea 
unu este facultativă 


O factură este emisă de un furnizor, î poate emite mai multe facturi sau nici t 


(0,M) 


Figura 2.9 Transformarea relaţiilor 1:N în care entitatea din partea unu este 
obligatorie 


2.4.2 Reprezentarea relaţiilor recursive 1:1 şi 1:M 


O relaţie recursivă de tipul 1:1 presupune existenţa unor perechi de 
instante ale entității între care există o legătură, indicată prin numele relaţiei. 
Aceste perechi pot fi opţionale sau obligatorii. In oricare din cazuri în tabela 
corespunzătoare entității se adaugă cheia străină sub un alt nume decât cheia 
principală, şi care poate lua valori nule dacă relaţia este opţională. Aceeaşi 
regulă se aplică şi în cazul unei relaţii recursive 1:M. 


Ar nu este obligatoriu. 


(0,1) (0,1) 


Este căsătorit cu 
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Figura 2.10 Transformarea relatiilor recursive 
2.4.3 Reprezentarea relatiilor binare M:N si relatiilor ternare 


Relaţiile binare de tipul M:N si relaţiile ternare, indiferent de tipul 
cardinalitatii, primesc acelaşi „tratament” la transformarea lor: se creează cate 
o tabelă pentru fiecare entitate implicată în relaţia analizată, la care se adaugă 
o nouă tabelă, ce va avea drept atribute cheile principale ale entităţilor 
asociate (şi care vor juca rolul de chei străine) şi eventualele proprietăţi ale 
relaţiei. In schimb, regulile de definire a cheii primare diferă în funcţie de 
ordinul şi cardinalitatea relaţiei. 

In figura 2.11 este prezentată relaţia binară Conţine dintre entităţile 
Produs şi Factura, cu cardinalitatea M:N. In urma transformării rezultă tabelele 
Produs şi Factura, corespunzătoare celor două entităţi, si tabela 
Articol factura. Această tabelă conţine cheile primare ale celor două entităţi 
asociate, precum şi atributele Cantitate şi Pret care erau iniţial proprietăţi ale 
relaţiei Conţine. De regulă, cheia noii tabele este formată prin combinarea 
cheilor celor două entităţi, după cum se vede şi în figura 2.11. În unele situaţii, 
combinaţia dintre cele două chei străine nu este suficientă pentru a juca rolul 
de cheie primară, fiind necesară includerea şi a altor atribute. 


Fiecare factură poate conţine mai multe produse tari prOdUS se poate regăsi pe mai multe facturi. 


| (0,M) 


Figura 2.11 Transformarea relaţiilor M:N 


Un tehnician poate lucra la mai multe proiecte, însă el intocmeşte o singură documentaţie pentru fiecare proiect în par 


Figura 2.12 Transformarea relatiilor ternare de tipul 1:1:1 


Stabilirea cheii primare pentru tabela rezultata in urma transformarii 
relatiilor ternare se face in functie de tipul relatiei, aplicandu-se urmatoarele 
reguli: 

1. Daca toate entitatile prezinta cardinalitatea maxima ,,unu”, atunci 
exista trei posibilitati de formare a cheii (trei chei candidat), 
rezultate prin combinarea oricaror doua dintre cele trei chei ale 
entitatilor originale; 

2. Daca doua dintre entitati prezinta cardinalitatea maxima ,,unu”, 
atunci vor exista două posibilităţi de formare a cheii: prin 
combinarea cheii principale a entității din partea „multe” cu una 
dintre cheile entităţilor situate de partea „unu”; 

3. Dacă o singură entitate prezintă cardinalitatea maximă „unu”, 
atunci cheia va fi formată prin combinarea cheilor principale ale 
celor două entităţi situate de partea „multe” a relaţiei; 

4. Dacă toate cele trei entităţi prezintă cardinalitatea maximă 
„Multe”, atunci cheia va fi formată prin combinarea cheilor tuturor 
celor trei entităţi asociate. 

În figura 2.12 este prezentat un exemplu de transformare a unei relaţii 
ternare cu cardinalitatea 1:1:1. Se observă crearea tabelei Doc proiect, care 
conţine cheile primare ale celor trei entităţi. Cheia primară este compusă din 
atributele Pr id şi Doc nr, însă mai există două chei candidat: Pr id şi Ang id 
sau Doc nr şi Ang id. 


xam nota 


Fiecare student susţine un examen cu un singur profesor, Însă el poate fi examinat de acelaşi profesor la mai multe dis 
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Figura 2.13 Transformarea relatiilor ternare de tipul 1:M:N 


Regulile de transformare a celorlalte tipuri de relatii ternare sunt 
aceleasi, cu exceptia celor pentru stabilirea cheii primare a tabelei copil. In 
figura 2.13 este prezentat un exemplu de transformare a relatiilor cu 
cardinalitatea 1:M:N, iar cheia primară a tabelei copil este formată prin 
combinarea cheilor primare ale entităţilor situate în partea „multe” a relaţiei, 
respectiv Stud id şi Disc id. Deoarece un student poate susţine examen la o 
disciplină de mai multe ori, combinaţia celor două chei străine nu este 
suficientă pentru a juca rolul de cheie primară, motiv pentru care s-a adăugat 
ca parte a cheii şi atributul Data exam. În exemplul de transformare a relaţiilor 
M:N:P din figura 2.14 avem o singură cheie candidat pentru tabela copil, dar 
care este formată prin combinarea cheilor primare ale tuturor celor trei entităţi 
asociate, respectiv Ang id, Form id şi Locm id. 


Fiecare angajat poate lucra in mai multe locuri de munta in formatii de lucru diferite, o formatie este formata din ma 
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Figura 2.14 Transformarea relatiilor ternare de tipul M:N:P 
2.4.4 Reprezentarea atributelor multivaloare 


Entitatile care au atribute multivaloare sunt supuse unui tratament 
special, creându-se două tabele: prima tabelă va conţine toate atributele 
entității, cu excepţia celor multivaloare, şi va avea aceeaşi cheie ca şi entitatea 
originală; a doua tabelă va conţine atributele multivaloare şi va avea cheia 
formată din cheia entității originale (care va juca şi rolul de cheie străină) şi 
unul sau mai multe din celelalte ADE: 


Atributele multivaloare Cota si Stare sunt separate = ellistincta. Ea se mai numeste si entitate atributiva. 
N 


Figura 2.15 Transformarea atributelor multivaloare 


În figura 2.15, transformarea entității Carte a dus la obținerea celor 
tabelelor Carte (tabela părinte) şi Copie (tabela copil). Ca particularitate a 
acestui exemplu, se poate observa că atributul ISBN nu face parte din cheia 
primară a tabelei Copie, deoarece unul din atributele multivaloare, Cota, 
poate juca singur rolul de cheie primară. 


2.5 Mecanismul tranzactional al bazei de date 


Gestiunea tranzactiilor se referă la problematica menţinerii bazei de date 
într-o stare consistentă in condițiile in care accesul la date se face în regim 
concurent sau in condițiile apariției unor defecte. Prin urmare, mecanismul 
tranzactional trebuie să rezolve următoarele două probleme: 

1 Controlul concurenței, adică sincronizarea acceselor astfel încât 
să fie menținută integritatea bazei de date. De regulă, această problemă este 
rezolvată prin intermediul mecanismelor de blocare. 

2 Rezistența la defecte, care se referă la tehnicile prin care se 
asigură atât toleranța sistemului fata de apariția unor defecte, cât si 
capacitatea de recuperare a acestuia, adică posibilitatea de revenire la o stare 
consistentă in urma apariției unui defect care a determinat rămânerea bazei de 
date într-o stare de inconsistenta. 

O bază de date este într-o stare consistentă dacă datele respectă toate 
restricţiile de integritate definite asupra lor: restricții privind cheia, restricții de 
integritate referentiala, restricţii specifice domeniului problemei (“business 
rules”). Trecerea bazei de date dintr-o stare în alta are loc atunci când se 
realizează operaţiuni de actualizare a datelor. Evident, orice operaţiune de 
actualizare asupra bazei de date trebuie să o lase într-o stare consistentă. 

Mecanismul tranzactional are la bază noţiunea de tranzacţie, motiv 
pentru care în continuare ne vom opri asupra definirii sale. 


2.5.1 Definirea şi proprietăţile conceptului de tranzacţie 
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Prin notiunea de tranzactie se intelege un ansamblu de operatiuni care 
sunt executate împreună asupra unei baze de date în vederea realizării unei 
activităţi. O tranzacţie reprezintă o unitate logică de prelucrare care asigură 
consistenţa bazei de date. Mecanismul tranzactional al bazei de date trebuie sa 
garanteze consistenţa bazei de date indiferent de faptul că tranzacţia a fost 
executată în mod concurent cu alte tranzacţii sau că au apărut 
disfunctionalitati în timpul execuţiei tranzacţiei. 

O tranzacţie simplă poate fi adăugarea unui nou client în baza de date, 
iar o tranzacţie mai complexă poate fi încasarea unei facturi, formată din 
următoarele operaţii: adăugarea unei înregistrări în tabela de încasări, 
actualizarea soldului pentru contul prin care s-a efectuat încasarea în tabela cu 
conturile firmei, şi actualizarea soldului clientului respectiv în tabela cu clienţii 
firmei. Pe timpul execuţiei unei tranzacţii, baza de date poate fi într-o stare 
inconsistentă, însă ea trebuie să fie într-o stare consistentă atât înainte, cât şi 
după execuţia tranzacţiei. 

Pentru ca o tranzacţie să garanteze consistenţa unei baze de date, ea 
trebuie să satisfacă patru condiţii, referite în literatura de specialitate prin 
acronimul ACID: 

e Atomicitate - o tranzacţie este considerată o unitate elementară de 
prelucrare, adică execuţia unei tranzacţii se face pe principiul totul sau nimic. 
O tranzacţie este validată numai dacă toate operaţiunile care o compun sunt 
validate, altfel datele trebuie restaurate în starea în care se aflau înainte de 
începerea tranzacţiei (tranzacţia nu poate fi parţial executată). Rezolvarea 
tranzacţiilor a căror execuţie a fost întreruptă din diverse cauze revine SGBD- 
ului. După eliminarea cauzei, în funcţie de stadiul de execuţie în care a rămas 
tranzacţia, SGBD-ul va proceda în unul dintre următoarele două moduri: fie va 
executa şi restul operaţiunilor care compun tranzacţia respectivă, terminând 
tranzacţia cu succes, fie va anula efectele operaţiunilor executate până în 
momentul întreruperii, anulând tranzacţia. 

e Consistenta - se referă la corectitudinea tranzacţiei din punctul de vedere 
al consistentei datelor. Trecerea de la o stare la alta a datelor în urma unei 
tranzacţii nu trebuie să afecteze consistenţa bazei de date. Tranzactia este 
corectă dacă transformă baza de date dintr-o stare consistentă într-o altă stare 
consistentă. Sarcina asigurării acestei proprietăţi revine proiectantilor şi 
programatorilor. 

e Izolarea - presupune ca orice tranzacţie să aibă acces doar la stările 
consistente ale bazei de date. Altfel spus, efectele unei tranzacţii nu sunt 
percepute de o altă tranzacţie decât după ce prima trazactie a fost comisă. De 
regulă, toate datele solicitate de o tranzacţie sunt blocate până în momentul 
finalizării ei astfel încât o altă tranzacţie să nu le poată modifica. 

e Durabilitatea - se referă la faptul că odată ce tranzacţia este validată, 
efectele sale devin permanente şi vor fi înscrise în baza de date. Efectele unei 
tranzacţii validate vor fi înscrise în baza de date chiar dacă după momentul 
validării apare un defect care împiedică înscrierea normală a rezultatelor 
tranzacţiei în baza de date; această activitate va fi realizată imediat după 
înlăturarea defectiunii ivite. Sarcina asigurării acestei proprietăţi revine SGBD- 
ului, iar mecanismul prin care este realizată are la bază conceptul de jurnal. 
Jurnalul este un fişier secvențial în care sunt înregistrate toate operaţiunile 
efectuate de fiecare tranzacţie din sistem. El evidenţiază toate operaţiunile 
executate deja, inclusiv starea dinainte şi cea de după a datelor. Dacă 
tranzacţia este complet executată, atunci modificările efectuate asupra datelor 
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vor fi permanentizate si se spune că tranzacţia a fost comisă; altfel, sistemul 
va utiliza jurnalul pentru a restaura baza de date în starea iniţială (cea 
dinaintea începerii tranzacţiei) şi se spune că tranzacţia a fost anulată. 

In cazul aplicaţiilor cu baze de date distribuite pot apare tranzacţii 
distribuite. Aceste tranzacţii fac mecanismul tranzactional mai complicat. De 
aceea, toate SGBD-urile care suportă tranzacţii distribuite trebuie să aibă un 
mecanism special de tratare a acestora, numit mecanismul de validare 
(comitere) în două faze. 


2.5.2 Mecanismul de comitere în două faze (Two-Phase Commit) 


O tranzacţie este distribuită dacă ea actualizează date gestionate pe mai 
multe noduri, adică ea accesează date din mai multe tabele aflate pe servere 
diferite. De exemplu, tranzacţia Adăugare vânzare nouă este o tranzacţie 
distribuită dacă ea presupune inserarea în tabelele cu facturi şi linii facturi, 
aflate pe un nod, actualizarea tabelelor cu clienţi şi stocuri, aflate pe alte două 
noduri. Această tranzacţie va fi descompusă în trei subtranzactii, transmise 
celor trei noduri implicate: cele două operaţiuni de insert, efectuate pe primul 
nod; operaţiunea de actualizare a soldului clientului, efectuată pe nodul pe 
care este rezidentă tabela cu clienţi; operaţiunea de actualizare a stocului 
produselor de pe factură, efectuată de cel de-al treilea nod, respectiv nodul pe 
care este stocată tabela cu stocuri. 

In exemplul nostru, fiecare din cele trei noduri va fi responsabil de 
garantarea locală a proprietăţilor ACID. În plus, mecanismul tranzactional în 
cazul tranzacţiilor distribuite trebuie să garanteze: 

e Atomicitatea globală, adică toate nodurile implicate în execuţia 
unei tranzacţii distribuite să finalizeze în acelaşi mod partea lor de 
tranzacţie (validarea sau anularea). Nu este permis ca unele noduri 
să valideze partea lor de tranzacţie, iar altele să o anuleze. 

e Evitarea blocărilor globale, în care mai multe noduri să fie 
blocate simultan. 

e Serializarea globală, care trebuie aplicată tuturor tranzacţiilor, 
distribuite şi locale. 

Atomicitatea globală a unei tranzacţii este asigurată de SGBD-uri prin 
intermediul mecanismului Two Phase Commit (2 PC). După cum 
sugerează şi numele, acest mecanism presupune validarea unei tranzacţii în 
două faze. In prima fază, fiecare server implicat (pe care se află datele 
actualizate de tranzacţie) execută partea sa din tranzacţie, dupa care 
transmite un mesaj către serverul de comitere, desemnat anterior, prin care-l 
anunţă că este pregătit să comită operaţiunile executate. Această fază mai 
este numită şi comiterea locală. Dacă toate serverele implicate validează 
operaţiunile executate, atunci serverul de comitere va înregistra tranzacţia şi 
va transmite un mesaj către toate serverele implicate pentru comiterea 
tranzacţiei. Astfel, tranzacţia este comisă, cu excepţia situaţiilor în care apar 
probleme de funcţionare la unul din servere; dacă cel puţin un server “cade” 
pe parcursul celei de-a două faze, serverul de comitere anulează întreaga 
tranzacţie şi instruieşte celelalte servere să anuleze operaţiunile pe care le-au 
executat. Această fază se mai numeşte comiterea/anularea globală. 

In cazul ORACLE, mecanismul 2 PC presupune parcurgerea a 
următoarelor TREI faze: 

e Faza de pregătire, în care coordonatorul global instruieşte toate 
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nodurile implicate sa pregătească comiterea tranzacţiei, cu 
excepţia nodului de comitere. Fiecare nod în parte va verifica dacă 
poate să comită tranzacţia şi va transmite răspunsul său 
coordonatorului global, rămânând în aşteptarea indicaţiilor 
acestuia dacă să comită sau să anuleze tranzacţia în funcţie de 
răspunsurile celorlalte noduri. Oricum, din momentul în care nodul 
a transmis răspunsul el va garanta fie comiterea tranzacţiei fie 
anularea acesteia. Din momentul în care toate nodurile sunt 
pregătite şi până la comiterea sau anularea modificărilor, se spune 
că tranzacţia este în dubiu. 

e Faza de validare realizează comiterea propriu-zisă a tranzacţiei 
distribuite (dacă toate nodurile au răspuns pozitiv). În această fază, 
coordonatorul global îi spune nodului de comitere să efectueze 
comiterea, iar după ce primeşte confirmarea de la acesta va 
transmite câte un mesaj tuturor nodurilor implicate prin care să le 
ceară să comită tranzacţia, după care va aştepta confirmările din 
partea acestora. In momentul în care au fost primite toate 
confirmările, faza de comitere este completă, iar consistenţa bazei 
de date globale este asigurată. 

e Faza de uitare, în care nodul de comitere şi coordonatorul global 
şterg toate informaţiile privind starea tranzacţiei ce tocmai a fost 
comisă. 

Dacă se întâmplă ca una din cele trei faze să nu poată fi realizată complet, 
atunci tranzacţia respectivă va fi în starea „în dubiu”. O tranzacţie distribuită 
poate ajunge în această stare datorită apariţiei unor defecte ale unuia din 
serverele de baze de date implicate, întreruperii conexiunii de reţea între două 
sau mai multe servere Oracle sau unor erori care privesc logica aplicaţiei 
utilizatorului (de exemplu apariţia unor erori care nu sunt gestionate prin 
program, iar aplicaţia se blochează). 

Mecanismul 2 PC din Oracle este complet transparent utilizatorilor. Totuși, 
intimităţile acestui mecanism trebuie cunoscute pentru a putea interveni în 
cunoştinţă de cauză dacă se ivesc unele probleme generate de întreruperea 
mecanismului. 

O altă problemă legată de procesarea tranzacţiilor priveşte utilizarea 
schemelor de blocare pentru protejarea înregistrărilor bazei de date pe 
timpul accesării acestora împotriva operaţiunilor de actualizare. Dacă o 
tranzacţie blochează o înregistrare, ea nu poate fi modificată decât după 
deblocarea ei. 

Când clientul solicită date, serverul le transmite în blocuri. Pentru a 
permite clientului să modifice datele, serverul trebuie să prevină modificarea 
datelor de către o altă aplicaţie după ce acestea au fost trimise clientului, 
blocând aceste date. 

Cel mai adesea se utilizează b/ocarea exclusivă, caz în care alte tranzacţii 
nu mai pot accesa datele astfel blocate. O alternativă o constituie controlul 
concurent optimist (optimistic concurrency control) care porneşte de la 
premisa că o înregistrare este, de regula, actualizată de o singură aplicaţie, la 
un moment dat. Această metodă asigură doar controlul coliziunilor legate de 
actualizare, în momentul comiterii. Dacă înregistrarea respectivă a fost citită 
de o altă aplicaţie, ea va fi instiintata de eventualele operaţiuni de actualizare. 
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